Traditionally, Digital Signal Processors (DSPs) have been used to run single channels, such as, for example, a single DS0 or time division multiplexed (TDM) slot, that handle single services, such as modem, vocoder, or packet processing. Multiple services or multiple channels require multiple DSPs, each running its own small executive program (small kernel) and application. The executive programs reserve some area in memory for application code. When applications need to be switched, these executive programs overlay this memory with the new application.
Channels may take one of the following forms: one channel carried on a physical wire or wireless medium between systems (also referred to as a circuit); time division multiplexed (TDM) channels in which signals from several sources such as telephones and computers are merged into a single stream of data and separated by a time interval; and frequency division multiplexed (FDM) channels in which signals from many sources are transmitted over a single cable by modulating each signal on a carrier at different frequencies.
Recent advances in processing capacity now allow a single chip to run multiple channels. With this increase in capacity has come a desire to run different services simultaneously and to switch between services.
A current method to implement multiple services or multiple channels involves writing custom versions of all control, overlay, and task-switching code. This requirement causes additional engineering overhead for development and debugging of the applications. In addition, not all services may fit into the memory available to the DSP, and the services must be swapped in from the host system. This swapping—overlaying—adds significant complexity to the implementation of the DSP services. The extra development activity consumes DSP application development time.
The fact that DSPs have a single thread of control creates problems to developing and debugging in the multi-channel, multi-service environment. Debugging an application on a single processor stops all other applications and channels running on that processor. If the processor is running, real-time diagnostics on a channel or service cannot be obtained without interfering with the operation of the other channels and services. In addition, a debugging system typically needs to have direct access to the chip being diagnosed. That is, a conventional debugging system must use a special development board or a physical debug interface (such as a Joint Test Access Group (JTAG) interface) to provide debugging access. This makes debugging in a production environment an inflexible and cumbersome process.
Therefore, what is required is an efficient way of debugging a target application in a multi-channel, multi-service environment, which will allow the developer to obtain real-time diagnostics without interfering with the operation of the target application and other running applications and which will perform debugging services remotely.